feat(gitlab): authenticate self-hosted GitLab via ASPECT_GITLAB_TOKEN#1237
feat(gitlab): authenticate self-hosted GitLab via ASPECT_GITLAB_TOKEN#1237b3cramer wants to merge 1 commit into
Conversation
The API-base override alone wasn't enough for self-hosted GitLab: the features only obtained a token by minting through the Aspect GitLab App, which is registered on gitlab.com and can't authenticate against another instance. Add gitlab_token_cache.resolve_token(), which returns (token, auth_kind): when ASPECT_GITLAB_TOKEN (a personal/group/project access token) is set it short-circuits the mint and uses the PRIVATE-TOKEN header convention; otherwise it falls back to the Aspect-App bearer mint as before. Thread the resolved auth_kind through every gitlab.* call in the three features alongside api_base, replacing the previously hard-coded "bearer". With this, self-hosted GitLab works end to end: CI_API_V4_URL (or an explicit ASPECT_GITLAB_API_URL) selects the host, ASPECT_GITLAB_TOKEN authenticates against it, and build/Web-UI URLs already derive from the native CI_SERVER_URL / CI_JOB_URL (build_metadata.axl, ci.axl). Adds resolve_token unit tests to lib/gitlab_test.axl.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a2a298aaef
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| return True | ||
| auth_reason = {} | ||
| token = gitlab_token_cache.get_or_mint( | ||
| token, auth_kind = gitlab_token_cache.resolve_token( |
There was a problem hiding this comment.
When ASPECT_GITLAB_TOKEN is used from a GitHub Actions runner (the explicit non-GitLab-CI path this change enables), this call can return the user's GitLab PAT. A few lines later the feature calls resolve_build_url(ctx, existing_app_token = token), and on GitHub Actions that resolver treats existing_app_token as a GitHub App token and sends it to the GitHub jobs API as Authorization: Bearer ... before falling back. That leaks the GitLab token to GitHub in this supported cross-CI configuration; avoid passing explicit GitLab tokens into the GitHub URL resolver, or skip that resolver when auth_kind == "private_token".
Useful? React with 👍 / 👎.
✨ Aspect Workflows Tasks📅 Tue Jun 16 04:01:29 UTC 2026
|
1 participant
Problem
#1235 made the GitLab API base configurable, but that alone doesn't unblock self-hosted GitLab. The three GitLab features (
GitlabCommitStatuses,GitlabStatusComments,GitlabLintComments) only ever obtained a token by minting through the Aspect GitLab App, which is an OAuth Application registered ongitlab.com. A token minted there can't authenticate against another instance, so pointingASPECT_GITLAB_API_URL/CI_API_V4_URLat a self-hosted host would 401 at the first API call.Every feature call was also hard-coded to
auth_kind = "bearer".Change
Add
gitlab_token_cache.resolve_token(), which returns(token, auth_kind):ASPECT_GITLAB_TOKEN(a personal / group / project access token withapiscope) is set, it short-circuits the mint and selects thePRIVATE-TOKENheader convention (auth_kind = "private_token"). No minting, no per-process caching. This is the self-hosted path.get_or_mint, unchanged.The resolved
auth_kindis threaded through everygitlab.*call in the three features (alongside theapi_baseadded in #1235), replacing the previously hard-coded"bearer".The remaining self-hosted touch points were already host-correct via native GitLab CI vars and need no change: build/Web-UI URLs derive from
CI_JOB_URL(ci.axl) andREPO_URLfromCI_SERVER_URL(build_metadata.axl).This is unit-tested plumbing, NOT validated against a live GitLab instance. No test in this PR makes an HTTP request to any GitLab API — not self-hosted, not gitlab.com. What's covered is the env→
(token, auth_kind)/ env→api_baseresolution logic and that the builtin graph loads. The claim that commit statuses / MR notes / discussions actually authenticate and post viaPRIVATE-TOKENagainst a self-hosted host is unverified and needs a live integration test before we tell customers it works.Changes are visible to end-users: yes
Searched for relevant documentation and updated as needed: documented in aspect-build/site#1072 (held as draft pending live validation)
Breaking change (forces users to change their own code or config): no — gitlab.com via the Aspect App is unchanged when
ASPECT_GITLAB_TOKENis unsetSuggested release notes appear below: yes
Adds an
ASPECT_GITLAB_TOKENpath (sent asPRIVATE-TOKEN) andASPECT_GITLAB_API_URLhost override so the GitLab features can target a non-gitlab.com instance. Not yet validated end-to-end against a live self-hosted instance — do not announce as supported until that lands.Test plan
Covered:
resolve_tokenunit cases inlib/gitlab_test.axl(explicit-token value +private_tokenselection; mint-fallback returns(None, "bearer")).aspect dev test-gitlab-client→gitlab.axl smoke: OK;aspect dev test-gitlab-features→OK;aspect tests axl→790 tests passed.NOT covered (follow-up before declaring self-hosted support):
ASPECT_GITLAB_TOKENagainst a real MR (gitlab.com is a valid proxy for thePRIVATE-TOKENcode path; a true self-hosted instance is the ideal) confirming a commit status, MR note, and inline discussion actually post.Builds on #1235.